Transcript

[0:00] Wir haben uns bei Midway dann tatsächlich auch für Oakleaf entschieden, genau weil es halt TypeScript ist und wir dann letztendlich gesagt haben, okay, die CLI ist für uns halt quasi auch eine Variante von Frontend.
Anscheinend kann ich mich ja auch authentifizieren. Oft so auch bei Git-Tools.
Wie kompliziert ist es denn, so einen Login zu machen?
Business as usual und macht man es freundlich oder ist es furchtbar kompliziert?
So, und wenn dir das jetzt alles nicht ausreicht, obwohl das ja schon echt mega gut klingt, dann hast du noch einen Tipp, wie man komplett eskalieren kann, korrekt?
Wie man komplett? Ich glaube, ich weiß, worauf du hinaus möchtest.
Richtig schön nerdig, total unnütz, aber ...

[0:44] Music.

[0:55] Revision 604.

[1:25] Leite eure Software-Abos und das Honorar unserer Audio-Producerin.
Wenn ihr euch auch beteiligen wollt, könnt ihr das unter patreon.com slash workingcraft sehr gerne machen.
Wir danken euch tausendfach für die Unterstützung und fürs weitere Zuhören.
Wir sind heute zu dritt. Aus dem Team hätten wir dabei die Vanessa.

Revision 604: UX auf der Kommandozeile

https://workingdraft.de/604/

[1:47] Servus. Ich bin der Shep. Und das bedeutet, wir haben wieder einen Gast da.
Und zwar den Martin. Hallo Martin. Moin.
Moin. Du warst noch nicht bei uns und Erstgäste bitten wir immer, sich mal kurz vorzustellen und zu sagen, wer sie sind, was sie machen.
Willst du mal erzählen? Ja, sehr gerne. Also erstmal vielen Dank, dass ihr mich hier haben wollt als Gast.
Es freut mich sehr. Genau, ich bin Martin.
Ich sitze in meinem Tagsüberleben bei Midwald, habe eigentlich einen Softwareentwicklungs-Background, und bin da in letzter Zeit aber so ein bisschen von weg. Also Softwareentwicklung gehört immer noch, Zum Kern meiner Tätigkeit, ich habe irgendwann so ein bisschen den Shift Richtung Software-Architektur und dann irgendwann Richtung Cloud-Architektur gemacht, war dann irgendwann bei Midwild übergreifend so für die Gesamtsoftware- und Cloud-Architektur von allem verantwortlich und habe jetzt in letzter Zeit so ein bisschen das Developer-Relations-Feld erkundet.

[2:51] Dazu gehört, ein bisschen den Kontakt zu Entwickler-Communities zu halten, Aber auch sowas wie mir Gedanken um die Developer Experience von der Produktwelt zu machen.
Das heißt, wie nehmen Entwickler, die mit unseren Produkten arbeiten, die sie überhaupt waren?
Das heißt zum Beispiel, wie intuitiv erschließen sich da die APIs?
Ist, also Developer-Experience so analog zur User-Experience, so ein bisschen ich, bin dafür verantwortlich irgendwie einen Plan zu erarbeiten, was so das Tooling angeht, was wir Entwicklern bereitstellen zu schauen, sind wir da gut aufgestellt, fehlt irgendwas, können wir Entwickler irgendwo in ihren Workflows unterstützen, Developer-Education gehört auch dazu, also ich schreibe viel Dokumentation schreibe zwischendurch mal einen Blogpost, Open Source ist ein großes Thema das heißt, ich kümmere mich so ein bisschen um unser Open-Source-Engagement.
Und um Use-Experience geht's ja auch heute. Also, das ist ja auch unser Thema.
Bevor wir da aber einsteigen, würde mich noch interessieren, wie findest du heraus, was Entwickler möchten?
Also, du musst ja dann quasi irgendwie zu denen gehen und mit denen irgendwie sprechen, arbeiten, Feedback einsammeln und so.
Genau so ist es. Also, hauptsächlich durch Sprechen und Zuhören.

[4:15] Und ja, auch so ein bisschen beobachten. Also was sind die Workflows?
Wie arbeiten die Leute mit den Produkten?
Und dann findet man häufig Anknüpfpunkte, wo man sich vielleicht integrieren kann, wo man besser unterstützen kann.

[4:31] Ja, und genau, uns interessiert heute ein bestimmter UX-Aspekt, den wir noch gar niemals, jemals beleuchtet haben, und zwar die UX von Kommandozeilenprogrammen letztendlich oder Kommandozeileninterfaces.
Ich weiß nicht, ob ich schon mal irgendwie eins gebaut habe. Ich glaube nicht.
Also das, was dem am nächsten kommt, ist vielleicht irgendwie Node, das irgendwelche Parameter übernimmt, die ich übergebe und dann Dinge tut.
Ansonsten habe ich Kommandozeilenprogramme vielleicht häufiger genutzt, aber das habe ich auch in der Vorbesprechung gesagt, wahrscheinlich gar nicht mal so genau drauf geachtet, wie die strukturiert sind.
Deswegen wird das eine hochspannende Folge, glaube ich.
Wie ist das mit dir, Vanessa? Hast du schon mal Kommandozeilen-Tools gebaut?
Ich weiß nicht, ob Plop-Files schreiben als Kommandozeilen-Anwendung gebaut schon gilt.
Ansonsten eher nicht. Ich hatte aber den gleichen Gedanken wie du.
Ich habe auch vorher mich gar nicht so darauf fokussiert, wie gut oder schlecht sie funktionieren, die ich benutze. Was aber vermutlich auch bedeutet, dass sie zumindest schon mal nicht so schlecht funktionieren, weil sonst wäre mir das vielleicht stärker aufgefallen.
Oder ich weiß auch eben einfach gar nicht, was alles möglich wäre. wäre.

[6:00] Und im Endeffekt habe ich mir auch nochmal gerade gedacht, im Endeffekt ist ja diese Art von Developer Experience dann auch einfach eine User Experience, weil jetzt sind ja wir auch mal die Nutzer, Nutzerinnen dann von diesen Sachen.
Mir ist dann nur auch heute im Laufe des Tages schon mal eingefallen, als ich schon mal an die Aufnahme gedacht habe, dass es da glaube ich so eine krasse Wetteranwendung gibt für die, für das Terminal, was wohl, ich muss es raussuchen, mir ist es gerade eingefallen, ich war aber unterwegs, ich schaue es mal raus, vielleicht finde ich da ein paar Bildchen davon, es ging mir mal, ging mir mal, meine Tweet sagt mir jetzt nicht mehr so, in sozialen Netzwerken ist mir da das mal untergekommen. Ein kleiner Hype.
Okay, eine Wetter-App auf der Kommandozeile, nicht schlecht.
Ja, aber warum nicht, ne?
Man kann, genau. Genau, also, richtig. Genau. Ja, genau.

[7:23] Dass man Maschinen provisionieren kann, was man über die Kommandozeile macht, weil Server jetzt ja keine grafischen Oberflächen haben.
Ist ja dann auch so, wenn man so seinen alten Windows-Server mit grafischen Interfaces hatte, dann war es irgendwann so, dass man einfach keinen Bock mehr hatte und dann doch lieber irgendwie dann auf die PowerShell gewechselt ist.
Aber was gibt es denn noch für Use Cases dafür?
Ich glaube, da gibt es mehrere. die vielleicht auch so ein bisschen parallel nebeneinander herlaufen.
Ich glaube, der erste geht tatsächlich schon in die Richtung, die du auch gerade angeschnitten hast.
Thema Provisionierung oder einfach Automatisierung.

[8:08] Weil viele von diesen CLIs ja dann auch den Vorteil bieten, dass ich sie halt ... Ich kann sie halt einerseits als Nutzer interaktiv benutzen.
Ich kann sie aber auch nicht interaktiv benutzen und skripten zum Beispiel damit.
Und das ist halt ein super spannender Punkt, wenn ich irgendwie Prozesse automatisieren möchte.

[8:28] Ohne mich jetzt irgendwie automatisch durch irgendeine Web-Nutzeroberfläche durchklicken zu müssen.
Oder mich jetzt, viele Anbieter bieten ja auch eine API an stattdessen, aber vielleicht will ich mich damit nicht auseinandersetzen.
Oder will nur irgendeine Kleinigkeit skripten und dafür so ein paar CLI-Aufrufe kann ich halt schnell in ein Shell-Skript oder PowerShell-Skript, kann man in PowerShell skripten?
Ich weiß es nicht. Ich habe keine Ahnung. Also, genau, ich hab den Sprung zur PowerShell auch ehrlich gesagt nie.
Also, ich bin ja so ein langjähriger Windows-Mensch, jetzt auf Mac frisch gewechselt.
Aber die PowerShell, die hab ich tatsächlich mir nie erschlossen.
Ja, also, da sind wir schon mindestens zu zweit, glaub ich.
Aber sie ist, glaub ich, powerful, so.
Ja. Und gibt's auch für andere Plattformen, so wie ich das mitbekommen hab.
Ja, guck. Genau, also, Automatisierung ist ein Punkt.
Wo ich auch immer so ein bisschen dran denke, ist, ich denke ganz häufig immer so an die Power-User.
Das heißt, die Leute, die, ich glaube, zu dem Lager gehöre ich halt auch.
Ich bin so im Arbeitsalter ganz, ganz viel auf der Kommandozeile unterwegs.
Und da freue ich mich ja, je mehr ich über die Kommandozeile machen kann, desto besser funktioniert mein Workflow irgendwie.
Also das beste Beispiel, was mir da irgendwie immer einfällt.

[9:57] Soll jetzt keine Werbung sein, aber so die GitHub-CLI zum Beispiel, das funktioniert wunderbar.
Ich bin da kaum noch in der Wettbewerbsfläche unterwegs.
Also alles, so der komplette Workflow, Repo runterladen, lokal entwickeln mit Git sowieso, das ist ja das Kernprinzip dabei.
So, aber dann Issue aufmachen, Pull-Request erstellen, Pull-Request reviewen, approven, mergen, das geht alles über die Kommandozeile und das macht meinen Workflow so viel einfacher.

[10:27] Dann beschleunigt den auch wahrscheinlich deutlich. Beschleunigt den immens.
Genau, weil du ja nicht mehrere Screens durchklicken musst. Du musst mit der Maus nicht von links oben nach rechts unten irgendwie dich bewegen.
Und du kannst auch, das ist auch was, was, finde ich, bei der Kommando-Fälle ganz häufig unterschätzt wird, dass du ja in einem Terminal-Fenster quasi nahtlos zwischen ganz, ganz vielen verschiedenen Kontexten wechseln kannst.
So, du musst jetzt nicht zwölf Browser-Tabs jonglieren, um zwischen GitHub, Midwald und deinem AWS-Konto hin und her zu switchen, sondern ...
Du sprichst mit einem Befehl das eine Programm an, so, zack, enter, nächste Zeile, dann das nächste Programm.
Du hast überhaupt keinen Kontext-Switch dazwischen und kannst viel effizienter arbeiten.
Mal kurz auf den GitHub-Fall nochmal zurück. Das heißt, du öffnest wirklich Pull-Requests samt der Description und sind da vielleicht auch Bilder mit da?
Bei meinen Frontend-Pull-Requests sind zum Beispiel oft Screenshots dabei.
Das würde damit auch alles einwandfrei gehen, weil ich gebe zu, dass ich mache, natürlich warst du gerade meines, ja die Standardsachen so, Git-Terminal, forken, pullen, pushen, rebasen etc.
Aber den Pull-Request erstellen mache ich tatsächlich in der GUI.
Das muss sich gestehen, ob man da jetzt ein Bild einbetten kann, das weiß ich nicht. Ich würde vermuten nicht.

[11:51] Wahrscheinlich hat das irgendjemand schon mal gemacht. Irgendjemand Nerdiges hockt da schon draußen und hat das schon mal rumgebastelt, dass man auch ein Bild hochladen kann.
Ja, das stimmt. Wobei, das könnte ich mir tatsächlich vorstellen, ist ein Prozess, der wahrscheinlich etwas komplizierter wäre, jetzt über einen Kommando-Zahl-Interface umzusetzen.
Man müsste es irgendwie hochladen, dann müsste man den Link irgendwie ins Markdown einbetten. Das ist ein kleines bisschen komplizierter, glaube ich.
Genau, vielleicht kann man das so, kann man sagen, so immer, wenn es um visuelle Dinge geht, braucht man ein visuelles Interface und wenn es um reine Textgeschichten geht, dann kann man mit einem Textinterface vielleicht effizienter arbeiten.
Ja, kann man glaube ich so sagen. Wobei die Terminals ja auch schlauer geworden sind.
Ich bin da jetzt nicht hundertprozentig firm, welches Terminal alles was unterstützt, aber so manche Terminals können mittlerweile auch Bilder darstellen.

[12:47] Naja, nee, da hab ich auch keine Ahnung. Aber da hat sich auf jeden Fall viel getan, vor allem in der Windows-Welt. Die haben ja auch gut aufgeholt.
Die hinkten ja arg hinterher. Ich glaube, die haben auch den Druck gespürt seitens der Anwender.
Ja, genau. Ich weiß ja nur, wie lange das gedauert hat, bis man da mal so Farben anzeigen konnte. Das ging ja auch nicht.
Ja, oder allein so was Billiges wie, du machst eine CMD auf und du willst mehr als 80 Zeichen Spaltenbreite haben.
Das war ja schon schwierig genug. Ja, stimmt.
Wir hatten jetzt ein Beispiel mit Git oder Git-Tools.
Trotzdem hast du mehrere konkrete Beispiele noch für uns, was so häufig wiederkehrende Aufgaben sind, die du da tatsächlich damit erledigst.
Oder du es anderes siehst, was die damit machen.
Ich denke jetzt mal, gut, das ist jetzt für mich das Heimspiel.
Ich denke jetzt mal so an Infrastructure oder Plattform ist der Servicebereich.
Da spielen wir natürlich mit, aber auch so ...
Ich glaub, Heroku haben, glaub ich, auch angefangen mit einer sehr, sehr coolen CLI.
AWS hat ein CLI-Tool, über das man auch, glaub ich, so mehr oder minder alles machen kann.
Wir arbeiten viel mit OpenStack, da gibt's eine super CLI.

[14:06] WordPress hat auch eine CLI. WordPress, stimmt, WordPress hat auch eine CLI. Das ist richtig cool.
Da muss man nicht irgendwie die ganzen Plugins zu Fuß installieren und so Zeugs, das ist echt mega.
Stimmt, genau. Typo 3 hat auch ein Äquivalent, das ist die Typo 3-Konsole.
Das funktioniert auch super.
Genau, und gerade wenn ich jetzt so an WordPress-Typo oder sowas denke, das ist halt auch ein Use Case.
Wenn ich zum Beispiel auf einem System unterwegs bin, wo ich gar keine grafische Oberfläche habe, ich bin per SSH auf irgendeinen Server hochkonnektiert.

[14:39] Dann gibt es da vielleicht tatsächlich nicht mehr als eine Kommandozeile.
Ja, und dann gibt es natürlich auch so diese ganzen Create-XY-App-CLIs und sowas wie Laravel Artisan oder so, die einem auch einfach viel Arbeit abnehmen, indem man die Kommandozeilen Cowboy oder Girl macht.
Also alles, was so in deinen Softwareentwicklungsprozess integriert ist, Also Projekt-Bootstrapping oder sei es alleine NPM.
Wie viele Sachen macht NPM oder Yarn?

[15:17] Das ist ja schon der Wahnsinn. Ja, und ich finde auch manchmal, dass tatsächlich so Programme schreiben, die irgendeinen Task lösen, meistens gar nicht.
Also das ist so relativ schnell gemacht. Aber wenn man dann noch die UI dazu braucht, dann fängt es an, echt nervig zu werden. Also zumindest ist das meine Erfahrung, dass UI immer am meisten Zeit kostet.
Also die Logik an sich ist schnell gebaut, aber dann will man die irgendwie exponieren. Und wenn man eben so grafische Interfaces hat, dann ist das eben viel Arbeit.
Wenn man das aber sozusagen auf die Kommandozeile verlegen kann, glaube ich, ist man vielleicht auch schneller am Ziel. Also...
Mit einfach einem anderen Ansatz. Du meinst, das ist so aus der Bausicht heraus?
Ja. Ja, weil ich finde es eigentlich aus der Nutzerinnen-Sicht ganz.

[16:11] Also es fällt mir jedes Mal wieder auf, wie langsam ich quasi unterwegs bin, wenn ich in irgendeinem Browser irgendwelche Sachen klicken muss, versus mit, ich kann das auf der Tastatur schnell erledigen.
Jetzt gibt es natürlich auch Tools, mit denen ich, die generell oft schon eine höhere Accessibility haben Oder zumindest eine sehr hohe Keyboard-Erreichbarkeit von den Sachen.
Ich glaube, bei VS Code generell komme ich ja auch mit Tastenkombinationen generell sehr weit.
Und ich glaube, dann fällt mir das am meisten auf, wenn ich in einem Browser bin und ich will solche Sachen machen, wie eine Zeile wegschneiden und woanders hin.
Und dann außerdem schließe ich einen Tab oder sowas, weil ich halt keine Ahnung was gedrückt habe.

[16:48] Also es ist unfassbar, wie viel schneller ich bin, wenn ich nicht auf Buttons drücken muss.

[16:56] Und selbst wenn die Webseite eine gute UX hat, allerdings es gibt ein Problemchen, was ich bei mir selber habe, wenn ich GitLab zum Beispiel verwende, weil ich es einfach selber persönlich ein bisschen anders machen würde.
Ich kann da auf meine Pull-Requests, Merge-Requests gehen und dann kann ich auf den Filter klicken, dass ich nur die sehen möchte, die mir assigned sind.
Aber dann scheine ich den Kontext da zu switchen, dass ich dann nicht mehr in meinem Projekt bin, in dem ich vorher war, sondern alle meine assigneden Merge-Requests über mehrere Projekte hinweg.
Und ich weiß immer nicht mehr, wie ich zurückkomme.
Ich muss immer ein neues Tab aufmachen und GitLab-Domain wieder eingeben.
Bevor ich jetzt gleich Infos bekomme, ich bin mir sicher, ich müsste nur auf den richtigen Button wieder zurückklicken.
Ich wollte nur sagen, es gibt immer so Sachen, wenn es grafisch ist, dass ich oft so ein bisschen drüber stolper, während es dann auf einer Kommandozeile halt alles auch Muscle Memory ist.
Schätzungsweise ist aber natürlich einfach die Einstiegshürde viel größer.
Etwas, was ich zum Beispiel auch immer noch kaum mit anschauen kann, ist bei anderen, die ihr.

[18:06] T-Mux, ich glaube T-Mux ist das, auf jeden Fall die, ach Item, die dann irgendwie ihre vier Fenster aufhaben mit Terminal und ich so, in welchem Fenster soll ich gucken? Wo bist du überhaupt? Wo ist der Cursor?
Das ist was, was ich nicht kann. Ich kann meinen WIM benutzen, ich weiß auch, wie man es exited.
Das ist ja die größte Herausforderung beim WIM.

[18:30] Das kann ich zum Beispiel nicht.

[18:34] Und Junta runterfahren funktioniert schon. Ja, da kommt man immer raus, meinst du, ne? Ja.
Etwas, was ich lange lernen musste, ist, wie ich einen Rebase, abbreche beim Verändern der Commit-Nachricht, weil ich irgendwann wusste ich nicht, wie ich rauskomme und dann habe ich einen Terminal-Tab schließen müssen, damit ich jetzt nicht aussehen was Falsches rebase.
Naja, passiert. Das ist aber auch irgendwie so ein Rite of Passage, sich mit dem Git-Rebase ins Knie zu schießen, oder? Also ich glaube, da musste jeder mal durch.
Ja, ist aber lang her bei mir.
Da war es eher so, dass ich, das hat jetzt gar nichts mit dem Rebase zu tun gehabt, glaube ich, wirklich nur ein Commit-Message-Reverten umbenennen.
Und ich habe aber aus Versehen eine Zeile zusammengefügt und ich wusste nicht, wie Command-Z geht. Genau, ich wusste nicht, wie Command-Z geht.

[19:27] Genau, also wir haben festgestellt, Kommandozeilen haben ihre Vorteile in verschiedenen Bereichen und jetzt sind wir natürlich alle total angespitzt und wollen selber mal irgendwie was bauen, was sich über die Kommandozeile benutzen lässt, anstatt über ein grafisches Interface.
Wie würden wir da anfangen? Sagen wir mal, wir würden irgendeine Utility bauen wollen.
Wie machen wir das? Also ich, genau, ich kenne halt so okay, Node, ich glaube da gibt es auch irgendwelche Möglichkeiten, dass Node dann irgendwie in eine also, dass man dann quasi so ein globales Command hat, das eben dann nicht mehr Node und dann JS-File ist, sondern dann einen eigenen Namen hat.
So, das kann man bauen, aber damit erschöpft sich das auch schon, was ich so darüber weiß.

[20:24] Genau, also du im Prinzip brauchst dir erstmal irgendeine Programmiersprache, die Daten auf der Standardausgabe ausgeben und irgendwie per Kommandozeile aufgerufen werden kann.
Das ist im Endeffekt eigentlich jede.
So, ich denke jetzt an dieses, die meisten Studenten machen im Studium irgendwann mal so eine Java Hello World Applikation, so die gibt einfach Hello World auf der Kommandozeile aus.
Das ist eigentlich so das Minimum, was man braucht.

[20:51] Die Frage der Laufzeitumgebung ist natürlich immer eine spannende, weil das dann ja auch eine Systemanforderung ist, die ich an den User stelle.
Wenn ich das jetzt in Java schreibe, dann erwarte ich vom User, der das Ding später benutzt, weil das ist ja keine Webanwendung, die ich jetzt über den Browser ausliefern kann, sondern der User muss das ganz klassisch bei sich lokal auf dem System installieren.
Und deswegen, dementsprechend, muss ich mir ein bisschen Gedanken machen, was für Systemanforderungen bringe ich da jetzt mit, mit was für Systemanforderungen lege ich den User auf.
Das heißt, das wären so Sprachen wie Go, die sich quasi mit dem Programm mitpackagen, wären wahrscheinlich da einfacher.
Das macht die Distribution am Ende tatsächlich am einfachsten.
Genau, irgendwie statisch kompiliertes Go-Binary, da kann nicht viel kaputt gehen.
Bei Rust wird es genauso einfach funktionieren, abgesehen davon, dass die Sprache noch eine etwas steilere Lernkurve mit sich bringt.

[21:55] Bei Node.js muss man sich ein paar Gedanken machen.
Man kann jetzt argumentieren, wenn deine primäre Zielgruppe jetzt sowieso Developer sind, ist die Wahrscheinlichkeit vielleicht eh hoch, dass du eine lokale Node.js Runtime installiert hast.
Dann kannst du einfach sagen, hier npm install-g und dann hast du das Ding installiert.
Man kann sich auch solcher Lösungen behelfen, die dir dann zum Beispiel noch deine eigene Node.js-Runtime in dein installierbares Paket mit einbetten.
Also das gibt's auch, da musst du's nicht selber installieren.
Sondern dann hast du quasi dein Installationspaket, da ist dann so ein eingebettetes Node.js mit drin.
Genau, was wiederum wahrscheinlich dann den Nachteil mit sich bringt, dass es relativ groß wird, das Paket. Ja, das stimmt, das stimmt.
Wir machen das bei unserer Mitwahl-TLI, also da machen wir genau das, das Ding ist in Node.js geschrieben und wir nutzen da quasi so einen vordefinierten, was ist das Wort, Paketierer?
Keine Ahnung, kann man das sagen? Ja, bestimmt. Ich habe es verstanden.
Ich finde, das klingt plausibel.
Genau, also der baut hier quasi so die fertigen Distributionspakete zusammen, da ist dann eine komplette Node.js-Distribution mit drin.
Vorteil ist, du hast am Ende eine ZIP-Datei, die kannst du entpacken, es ist alles drin und es läuft.
Nachteil ist, das Ding ist dann 50, 60, 70, 100 MB groß.

[23:19] Ja, sag mal, es ist nicht das ressourcenschonendste, was man machen kann, aber, zumindest so in unseren Kreisen sollte das ja recht verkraftbar sein.
Ich frage mich gerade, ob bei Cloudflare, die haben ja Wrangler als Kommandozeileninterface oder Tool, ob die das nicht eventuell ganz ganz genau so machen.
Bin ich mir nicht ganz sicher. Das kann ich gerade auch nicht sagen, aber kann gut sein.
Das heißt also im Grunde, man kann jede Sprache nehmen, um ein Commando-Tool zu schreiben.
Vielleicht fängt man am Anfang, wenn man erst mal nur für sich selber baut, kann man ja dann nehmen, was man möchte.
Also bei uns im Podcast, uns hören vorwiegend Frontend-Entwicklerinnen und da würde ich jetzt mal sagen, wird das vielleicht irgendwas Node-JavaScript-basiertes sein.
Genau, und wenn man dann aber sozusagen wenn man das dann verteilt, dann ist vielleicht der Ansatz, nicht so gut oder dann sollte man zumindest das zusammen bundeln, die Runtime und den Code, wie auch immer das dann passiert.

[24:33] Okay.
Ähm, genau, aber dann kann man, äh, also das ist jetzt sozusagen der Bare-Bones-Ansatz, dass man erstmal so quasi die eingebauten Möglichkeiten der Programmiersprachen nutzt, aber wie das immer so ist, ist ja im Browser auch nicht anders.
Das ist halt sehr viel zu Fuß Arbeit und du weißt von Kommandozeilen, Frameworks, also die einem so wahrscheinlich ganz viel Legwork abnehmen, das mir jetzt gerade nicht bekannt ist, dieses Legwork, aber du erzählst mir das jetzt gleich mal oder uns.
Genau, diese Frameworks machen dann Sinn, weil du ja eigentlich bei jeder Kommandozeile immer die gleichen Probleme hast.
Du musst dir irgendwie überlegen, wie kriegst du User, wie nimmst du User-Input entgegen.
Die meisten Kommandozeilen-Tools, die haben ja diese...
Es ist kein Naturgesetz, aber das ist irgendwie so eine Konvention, die sich so etabliert hat, dass man irgendwie Flags und Argumente entgegennehmen kann.
Also diese Flags mit minus minus keine Ahnung was, so minus minus help im einfachsten Fall.
Das ist schon die erste Konvention, dass ich einen Befehl vielleicht mit minus minus help aufrufen können soll, weil die Leute einfach implizit davon ausgehen, dass das geht.

[26:01] Sagst du nochmal kurz was, also so einfach so, ich glaube so intuitiv wissen wir das schon, aber was ist der Unterschied zwischen Flags und Argumenten also wo unterscheiden die sich, genau also die Konvention ist eigentlich, dass, Flags sind häufig mit minus minus Name konnotiert können dann noch einen Wert haben, vielleicht auch nicht, dann ist es einfach ein Boolean Flag, sind häufig Häufig, vielleicht auch nicht immer, das ist wie gesagt, Konventionen kann man sich dran halten, muss man nicht, sind häufig optional.
Argumente sind dann nur durch ihre Positionen, identifiziert. Okay, und es gibt aber doch manche Kommandozeilen, also ich sag jetzt mal so FFmpeg, glaube ich.
Also das ist ja so ein totales Kommandozeilen-Interface-Monster.
Ja.
Hat das nicht auch noch einfach nur Bindestrich I für Input oder so?
Und dann gibt man danach den Wert.
Also das ist dann sozusagen einfach nur eine andere Konvention, dass man die Argumente, dann kann man quasi die Reihenfolge der Argumente wahrscheinlich auch ändern.
Genau, das ist auch eine Konvention, dass du bei.

[27:14] Flags irgendeine Art von Shorthand angeben kannst.
Also ganz häufig hast du es so, du hast irgendwie minus minus Input und weil Entwickler ja tendenziell faule Leute sind und sich jeden Tastaturanschlag gerne sparen möchten, gibt es dann minus i als Kurzform dafür.
Das ist, wie gesagt, sagt die Konvention.
Gerade auch für Dev-Dependencies zu installieren, minus D. Stimmt.
Ja, und da musst du wieder mal aufpassen, minus Groß-D, minus Klein-D.

[27:47] Ja, da habe ich aber noch nicht rausgefunden, zumindest wäre es für mich nicht intuitiv gewesen, sondern diese Sachen habe ich mir dann irgendwann einfach auswendig gemerkt, gerade wenn ich mal umher hüpfe zwischen NPM und Jan, dann drücke ich oder schreibe ich erst mal fünfmal hintereinander das Falsche, bis ich dann dann wieder das richtige Kürzel schreibe.
Gerade glaube ich, dass es bei npm install ist und bei yarn ist es add für den Package.
Aber ich war mir tatsächlich auch immer so ein bisschen unsicher, darf ich die Flags mit minus minus überall hinsetzen oder nicht?
Meistens hat es geklappt.

[28:26] Manchmal nicht.
Aber inwiefern? Also wo hast du den Gedanken, dass du sie vielleicht nicht setzen könntest?
Je komplizierter zum Beispiel auch die Skripte werden. Also du kannst ja zum Beispiel, wenn du jetzt, nehmen wir mal Webpack her, wenn du jetzt Webpack installiert hast, dann kannst du ja mit NPM oder mit YARN mit den festgelegten Skripten, die du vielleicht auch in der Package-Log jetzt hinterlegt hast, also Package-JSON, also jetzt sehr Frontend-lastig, die YARN- oder NPM-Skripte ausführen.
Aber du kannst ja stattdessen auch einfach Node ausführen und sagst dann eben Node und dann suchen wir bei Node Modules bin Webpack irgendwie die Datei raus und dann führen wir das folgende aus.
Das habe ich hin und wieder gemacht, wenn ich dann zum Beispiel mir die Memory Leaks oder Ähnliches anschauen möchte oder ich möchte generell den Verbrauch davon anschauen.
Das heißt, ich verbinde ja sozusagen jetzt ein Node-Skript mit einem Webpack-Skript und dann war das, ich habe ja jetzt Flags für, wie ich Node ausführen möchte und ich habe Flags dafür für Webpack selber und dann war ich mir, dann, dann, dann, dann, genau. Genau.

[29:40] Das verkompliziert die Sache dann noch so ein bisschen. Also gerade so bei den Interpretersprachen, so wie Node.js, wo du dann noch Flags an den Interpreter wieder mitgeben kannst, der ja quasi dann sein ...
Genau, das war jetzt, dass ein Fachwörter erklärt, was ich sagen wollte.
Das müsste man einfach eskalieren mit noch mehr Bindestrichen.
Der Interpreter, der kriegt dann drei Bindestriche und das Betriebssystem wiederum kriegt vier. das da drunter liegt.
Ja, aber dann im Endeffekt sind es halt, wie gesagt, Conventions.
Ich glaube, bei NPM und YARN zum Beispiel installiere ich Packages jeweils so ein bisschen anders. Einmal ist es Add, einmal ist es Install.
Bei NPM geht es, das weiß ich fast hundertprozentig, geht auch einfach nur I.
Ich habe jetzt noch nie versucht, YARN A zu schreiben für YARN Add.
Im Endeffekt habe ich dann auch sehr oft mir einfach in meinem OhMyZSH mir die Aliases angelegt.
Von daher komme ich dann auf einem anderen Terminal nicht mehr klar, weil ich meinen Branch nicht mehr so auschecken kann, wie ich das gewohnt bin.
Dann geht GCO auf einmal gar nicht mehr.

[30:48] Ohne diese OhMyZSH-Git-Aliase könnte ich auch nicht mehr leben.
Ja, ohne ... Ich habe tatsächlich meinen Laptop so clean wie möglich eingestellt.
Wir hatten ja auch gerade in der letzten Revision, war das glaube ich, erst darüber gesprochen, welche Tools wir alle so benutzen und etc.

[31:08] Und ich versuche eigentlich tatsächlich so wenig wie möglich zu benutzen oder es so selber einzustellen und ich weiß, man kann alles in irgendeine Cloud und Backup hochladen, aber ich will immer in der Lage sein, egal mit welchem Laptop man mir gerade hinstellt, einfach arbeiten zu können oder auch andersherum, sodass die größte Hürde vielleicht einfach nur, es ist ein deutsches Tastatur-Layout oder ein englisches Tastatur-Layout ist.
Aber was ich immer machen muss, auch wenn ich mich dann auch irgendwie auf eine Ubuntu-Maschine oder sowas einlogge, ich muss mir irgendwie dann Terminal und ohmyzsh installieren.
Also ich komme mit meinem Standard-Terminal so bedingt weit, aber irgendwann macht das keinen Sinn mehr.
So brew und ohmyzsh muss da drauf.
Ansonsten ist es egal. Ach genau, was ich gerade noch sagen wollte, und sehr oft geht sowas wie "-help", oder "-list", beziehungsweise sehr oft geht "-h", oder "-h", dann komme ich aber auch schon wieder durcheinander, und "-l", für Liste, aber manchmal geht nur die lange Form, und das hat natürlich jetzt nichts mit der Programmiersprache zu tun, sondern wie wurde es konfiguriert, und das ist ja jetzt quasi die Richtung User Experience. Ja, genau.
Wir sind ja bei den Frameworks so ein bisschen da hingekommen.
Genau, ich wollte grad sagen, die bringen ja dann sozusagen einen Serviervorschlag mit, vermute ich, oder?
Genau, und sie nehmen dir halt auch diese ganze Verarbeitung deiner Flags und Argumente irgendwie ab. Weil ansonsten ... Ist ein bisschen Brandwerk.

[32:31] Genau, stell dir vor, du hast irgendwie ein ultrakompliziertes Kommando, da kommen dann irgendwie zwölf Flags mit rein, von denen irgendwie noch manche Werte haben und manche nicht.
Und dann wiederholen sich manche von denen noch und dann irgendwie noch drei Numere für Argumente irgendwie dahinter.
Stimmt, und manche können sich ja quasi widersprechen. Ja, genau.
So, run in, also parallel, also parallel abladen, oder Max Workers, vier, aber bitteschön run in band. So, was denn jetzt?
Genau. Ach stimmt, da kommen ja auch Fehlermeldungen zurück.
Die muss ja auch irgendjemand schreiben.
Die muss auch jemand schreiben. Ja, habe ich ja noch nie drüber nachgedacht.
Das hat immer einfach funktioniert.
Das sind aber alles Sachen, für die diese Frameworks dann gut sind. Ja, nee, klingt super.
Weil wenn du jetzt einfach ein ganz billiges Node.js-Programm schreibst oder Java-Programm oder keine Ahnung was, dann kriegst du halt dein String-Array, da ist irgendwie alles drin.
Und dann, herzlichen Glückwunsch, du darfst das jetzt alles selber verarbeiten.

[33:26] Ja, nee, nee, ich erinnere, wie gesagt, es ist wirklich kein Vergleich bestimmt zu dem, was du an Erfahrung schon sammeln konntest.
Aber bei den kleinen Plop-Files, die ich geschrieben hab, damit ich mir halt auch mal solche Skeletonsachen erstellen kann kann für, wir haben das relativ oft im Einsatz für API-Requests erstellen, also ob das ein Get- oder Post-Request ist, und da hatte ich halt so ein bisschen so ein, damit ich halt mal möglichst, ohne selber viel zu tippen, so ein Fetch-Request mir printen kann mit Payload und Headern und Query-Parametern vielleicht, und da ist mir dann auch aufgefallen, eigentlich müsste ich jetzt schauen, ob das mit der richtigen Syntax kommt, ob da Leerzeichen dazwischen sind, die muss ich dann trimmen.
Ja, dann ist mir aufgefallen, auch für die Kommandozeile gibt es ganz schön viele Edge Cases zu berücksichtigen.

[34:14] Ja, es ist am Ende des Tages genauso wie im Web auch, wenn du einen Form-Input validieren willst.
Es ist User-Input, wenn da ein Input reinkommt, der nicht dem entspricht, was du erwartest, dann hast du auf der CLI natürlich genauso die Herausforderung, das dem User irgendwie ansprechend zu präsentieren und ihm auch klarzumachen, was jetzt der erwartete Input war und was du falsch gemacht hast. Mhm.
Das ist ja im Web genauso frustrierend. Du hast irgendwie ein Riesenformular mit zwölf verschiedenen Feldern und gibst alles ein und am Ende kommt einfach nur, Eingabe ist ungültig, aber ich sag dir nicht wo.
Vermutlich gehören dann auch solche Sachen dazu, dass man eine Default-Antwort geben kann, wie Yes or No, dass wenn ich einfach nur Enter drücke, dass eins von den beiden schon der Default ist.
Weil das auch gefährlich sein kann, wenn Yes dann der Default ist.
Ja. Wollen sie wirklich alles löffnen? Ja, Enter O. Ups. Klar.
Ich bin ja immer noch dankbar, dass das RM, wenn man es mit minus R auf Slash aufruft, noch irgendwie dreimal nachfragt, ob du wirklich sicher bist, dass man das wirklich will.
Also das hat mir schon mindestens einmal die Root-Partition gerettet.

[35:35] Ich weiß gar nicht, hast du schon Framework-Namen genannt? Was würde ich jetzt googeln?
ChatGPT oder was auch immer. Was würde ich jetzt suchen, wenn ich damit starten möchte mit einem Framework?
Ich würde generell googeln nach Name der Programmiersprache deiner Wahl und dann das hierleine Framework.
Da gibt's eigentlich fast für jede von den Mainstream-Programmiersprachen so mindestens zwei, drei solide Frameworks, die das alles abnehmen.
Wir was gibt's denn da so bei ich komm so hauptsächlich aus der Go-Welt, da ist Cobra zum Beispiel ganz groß unterwegs die Kubernetes-User kennen das wahrscheinlich weil kubectl halt da mitgebaut ist, dann im in der PHP-Welt gibt's die Symfony-Konsole Python hat Click, und so in der JavaScript-Welt also was ich bisher Commander gibt es, so in der JavaScript-Welt, Was ich mittlerweile eigentlich am liebsten habe, gerade so in der JavaScript- oder TypeScript-Welt eigentlich eher, also ich muss mich jetzt kurz outen, ich mache eigentlich so gut wie gar kein JavaScript, ich mache nur TypeScript.
Gerade so in der TypeScript-Welt hat mir Oakcliffe eigentlich sehr gut gefallen oder O-C-L-I-F oder ich weiß bis heute nicht, wie man es ausspricht.
Also das OpenCLI-Framework heißt es in voller Länge.

[37:03] Genau, das ist, das hat damals Ich muss aufpassen, dass ich jetzt nichts Falsches erzähle Ich glaub Heroku haben das gestartet und damals dann Open Source.

[37:15] Das dürfte dann wahrscheinlich auch das Framework sein, auf das unsere Hörerinnen am schärfsten sind, unterstelle ich jetzt einfach mal.
Zumindest bin es ich, sagt man es einfach so. Genau.
Also andere Programmiersprachen programmieren die höchstwahrscheinlich auch, aber ich glaube, das meiste dreht sich ja dann doch um diese Geschichten.
Wir haben uns bei Midway dann tatsächlich auch für Oakleaf entschieden, genau weil es halt TypeScript ist Und wir dann letztendlich gesagt haben, okay, die CLI ist für uns halt quasi auch eine Variante von Frontend, so halt Web-Frontend und CLI-Frontend.
Und die Weiterentwicklung davon liegt dann in den einzelnen Entwicklungsteams, die dafür verantwortlich sind, ein bestimmtes Teilprodukt jetzt irgendwie voranzutreiben.
Deswegen war so das vorhandene JavaScript, TypeScript-Know-how in unseren Entwicklungsteams, die dann halt auch viel Frontend, klassische Web-Frontend-Development machen.
Jetzt muss ich mich aufpassen, dass ich mich nicht mit der Frontend-Entwicklung verzettel, so CLI-Frontend, Web-Frontend und so, weil das Know-how halt da war.
Das war jetzt keine neue Technologie.

[38:25] Wir mussten jetzt nicht Entwicklungsteams, die gewohnt waren, ausschließlich mit TypeScript zu arbeiten, weil sie im Backend halt auch mit TypeScript arbeiten, Dann jetzt noch zu sagen, ihr herzlichen Glückwunsch, ihr ist dieses Go-Ding, jetzt dürft ihr noch Go lernen oder Python oder Rust oder keine Ahnung was.
Ja, und ich vermute, dass die EntwicklerInnen dann auch Codesharing betreiben können, wahrscheinlich zwischen den Web-Interface-gesteuerten Dingen und eben den Kommandozeilen-gesteuerten Dingen.

[38:59] Das ist tatsächlich so, genau. Also wir haben für unsere API eine Client-Bibliothek, die ist weitgehend einfach automatisch generiert aus einer Open-API-Spec, die kannst du per NPM installieren.
Und die wird tatsächlich im Web-Frontend und auch von der CLI genutzt.
Das ist sehr, sehr praktisch. Und dann hast du so die größten Teile.
Okay. Also dann hast du schon sehr, sehr viel geshared zwischen den zwei Komponenten.
Und du hast ja gerade gesagt, du benutzt TypeScript.
Und in den Shownotes hast du native TypeScript-Unterstützung geschrieben bei diesem Framework. Das bedeutet aber letztendlich, also das wird am Ende auch einfach kompiliert, oder?
Genau, es wird am Ende kompiliert.
Was ich damit meinte ist, du hast bei OakLift die Möglichkeit, Commands zu definieren.
Jedes Command ist dann am Ende eine TypeScript-Klasse.
Und du definierst in der Klasse zum Beispiel, welche Flags nimmt dieses Command entgegen.
Also zum Beispiel, du willst einen Minus-Minus-Input-Flag haben und das muss auf jeden Fall ein String sein.
Dann macht Oakcliffe irgendeine sehr, sehr abgefahrene Typing-Magic, von der ich lügen würde, wenn ich behaupten würde, sie vollends durchblickt zu haben.

[40:28] Auf jeden Fall kriegt der Compiler das mit, dass es dieses Flag gibt und welchen, Datentyp dieses Flag hat.
Und wenn du dann am Ende vorher als String definiertes Flag als Integer versuchst zu behandeln, dann schreit der Compiler dich halt an, wie du es von TypeScript kennst und liebst.
Ja, macht auf jeden Fall Sinn. Genau, und du hast gesagt, jedes, also für jedes, Command, Subcommand letztlich, also Also, weiß ich nicht, sowas wie, was Vanessa gerade meinte, List oder sowas.
Schreibst du, hast du gesagt, eine Klasse pro Subcommand? Eine Klasse pro Subcommand, genau.
Genau, das wird dann auch auf jeden Fall gut aufgeräumt und gut durchstrukturiert.

[41:19] Ich würde fast noch ein bisschen mehr in die Designrichtung fragen.
Also, wir hatten jetzt sehr viel mit Inputs.
Aber jetzt, es fällt mir ein bisschen schwierig zu fragen, weil ich ja die Tools jetzt nicht so wirklich ausgiebig benutze.
Aber was ich weiß, und das weiß ich ja eben auch von diesen Wetterdingens, das ich da mal gefunden hatte, manchmal kommt da nicht nur eine Antwort, die einfach so aus dem Satz besteht, sondern manchmal kommen da so Antworten, wie auch so mit Tabellen oder mit Farben.
Wie schwierig ist das denn alles? Und hat da das Framework auch schon Hilfen dafür?
Oder ist das dann selbst dabei? Oder gibt es da so Frameworks auf Frameworks?
Kann ich mir da noch Libraries reinziehen?
Wie funktioniert das denn? Ja, also das geht alles.
Also Oakleaf zum Beispiel bietet, bringt Helper-Funktionen für so die wichtigsten Sachen mit.
Daten tabellarisch ausgeben zum Beispiel. Das habe ich auch bei Test-Coverages und so was. Kommt ja irgendwie zu Tabellen. Genau.
Oakleaf ist zum Beispiel sogar schon intelligent genug, wenn du jetzt eine Tabelle ausgibst über das Framework, sich auch automatisch an die Terminal-Breite anzupassen.
Wow, das ist ja wie Breakpoints. Ja. Responsive Design. Geht das mit Table?
Responsive CLI-Design, mega.

[42:41] Ja, das geht, das geht. Also du kannst über so ein bisschen TTY-Magic, kannst du die Breite des Terminals abfragen und dann darauf deinen Output anpassen.
Das funktioniert tatsächlich.
Vermutlich dann ohne Observer, dass wenn ich das resize, es sich nicht automatisch anfasst.
Ja, genau. Du hast ja sowieso meistens, ja, kommt drauf an, du hast ja sowieso ganz häufig keine jetzt ständig laufende Anwendung, sondern du hast da einen Befehl, führst den aus, der printet dir dann seinen Output aufs Terminal und dann ist das Programm zu Ende.
Es gibt natürlich auch diese CLIs, die quasi kontinuierlich laufen, die dann wirklich interaktiv Nutzer-Input verarbeiten.
Die gibt es auch. Da bin ich so ein bisschen zwiegespaltener Meinung, weil das natürlich so mit Scripting überhaupt nicht funktioniert.
Also wenn du jetzt so eine CLI irgendwie in einem Skript verwenden möchtest und das Ding reagiert nur auf interaktiven Input und läuft dann quasi kontinuierlich, das ist ein bisschen schwierig miteinander vereinbar.
Hat man ja auch meistens eher nicht. Ja, genau.

[43:49] Genau, und dann, das Oakcliffe bietet dann auch ein, oder hat auch eine Paketierung mit integriert, korrekt?
Also das wäre dann wahrscheinlich das, was du meintest, dass man dann vielleicht die Node-Runtime mit da rein bundelt oder so was?
Genau, das macht er sehr, sehr komfortabel. Also das ist dann am Ende ein ...
Oakcliffe nimmt das auch mit dem Dogfooding sehr, sehr ernst.
Das heißt, wir bieten auch selber für das Bauen von CLI-Anwendungen eine eigene CLI-Anwendung.

[44:24] So ein bisschen CLI-ception, die da an den Tag gelegt wird.
Die Oakcliffe CLI selber, die bietet dann auch tatsächlich sehr, sehr gute Werkzeuge, um diese ganze Paketierung zu übernehmen.
Das heißt, du kriegst automatisch Pakete für Windows, Linux und Mac.
Kriegst auch einen, für Windows kriegst du auch einen, tatsächlich einen richtigen Installer, wenn du es möchtest.
Ja, so ein MSI-Ding, was man dann irgendwie ausführen kann.
Ja, weil gerade unter Windows, da möchtest du nicht irgendeinen Tarball entpacken, also entpack unter Windows erstmal eine Tarball, da fängt es ja schon an.
Du willst da nicht irgendeinen Tarball entpacken und den dann von Hand irgendwo in den Path reinwerfen, das ist halt ein Problem.
Da ist so ein richtiger Installer halt schon ganz cool und das bietet Oakleaf halt alles out of the box.
Für MacOS kriegst du auch eine PKG-Datei, die du dann auch direkt installieren kannst.

[45:22] Wobei, da muss ich dazu, also da solltest du dann auch das Apple Developer Certificate haben, damit du den Kram dann auch signieren kannst, weil sonst schreit macOS beim Installieren dich halt an. Ja, Klassiker.
Klassiker.

[45:34] Genau, und dann bieten die auch, wenn ich das hier richtig verstehe, auch ein Update-Mechanismus, wie du, also das, ich verstehe das so, dass du dann sozusagen ein Auto-Update-Mechanismus hast, wo du dann Updates pushen kannst, zu den Usern, richtig?
Das geht auch. Das ist bei Oakleaf ein Plugin.
Das funktioniert dann quasi so, also du puffst es nicht wirklich, das Plugin checkt quasi irgendwie so in, regulären oder irregulären Abständen, das müsste ich in der Readme jetzt nochmal genau nachlesen, ob es quasi eine neuere Version von sich selbst gibt und dann kann er sich selber updaten. Das funktioniert.
Du musst dafür die diese Distribution Starballs musst du dafür irgendwie in einen AWS S3 Bucket oder sowas pushen.
Oder halt irgendwo ins Netz, wo der Updater gucken kann, gibt's jetzt eine neue Version von mir selbst.
Ja, gut, das macht Sinn. Also, sonst kann das ja schlecht funktionieren, wenn man ihm nicht vorab sagt, wo er immer nachgucken muss, an welcher Stelle.
Genau. Ja. Und so gerade so Updates ausrollen ist halt auch super wichtig bei so einer CLI, weil so bei einer Web-Anwendung hat man das Problem nicht, weil die wird ja sowieso über den Browser ausgeliefert.

[46:55] Und du willst den User jetzt ja auch nicht jedes Mal dazu zwingen, jetzt diesen MSI-Installer nochmal wieder neu runterzuladen.
Vor allem, wie sagst du ihm das, dass er das jetzt tun muss?
Wenn er nicht von alleine auf die Idee kommt, mal zu gucken, hey, gibt's irgendwie ein Update?
So, bei Desktop-Anwendungen ist das noch so ein bisschen einfacher, so die kannst du irgendwie dann zumindest über die üblichen App-Stores oder bei Linux irgendwie über die Repos verteilen, so dann kriegst du sie über die automatischen Updates irgendwie mit und so irgendeinen Mechanismus, um Updates auszurollen, braucht man halt, wenn du möchtest, dass deine User irgendwie auf einer, sagen wir mal, halbwegs aktuellen Version deiner Software arbeiten.

[47:39] Ja. Cool. So, und wenn dir das jetzt alles nicht ausreicht, obwohl das ja schon echt mega gut klingt ...
Dann hast du noch einen Tipp, wie man komplett eskalieren kann, korrekt? Wie man komplett, ich glaube, ich weiß, worauf du hinaus willst.

[48:00] Dafür würde ich nochmal an Vanessas Frage andocken, die du vorhin gerade gestellt hast. Ich bin da so ein bisschen drüber weggegangen.
Du kannst natürlich in diesen ganzen CLI-Anwendungen noch an Node-Bibliotheken nachinstallieren, was man will.
Wenn du jetzt sagst, dieser Standard-Tabellenhelfer, den Oaklyft zum Beispiel anbietet, der reicht mir nicht, weil ich irgendwie was Schickeres haben möchte.
So Color-Output oder sowas ist im Übrigen überhaupt kein Problem.
Also da gibt es auch ganz viele Helferfunktionen für, die irgendwie farbigen Output auf dem Terminal anbieten.
Also das ist kein Problem, wobei man da vorsichtig sein muss, wieder wenn es jetzt zum Beispiel um Scripting oder sowas geht.
Also dann braucht man meistens irgendwie einen Mechanismus, um zu gucken, laufe ich jetzt gerade in einem Terminal oder laufe ich in einem Script, weil dann will ich die ganzen bunten Farben da meistens nicht drin haben.
Ja, zu Color-Befehle, die sehe ich ja auch hin und wieder bei fast allen Sachen, die ich benutze.
Was ich aber zum Beispiel selber sehr selten sehe und dementsprechend auch davon ausgehe, dass es vielleicht gar nicht so easy ist, wäre, ich habe ja vorher schon gesagt, Test-Coverage.
Und es gibt jetzt so ein paar Skripte, die brauchen so ein bisschen länger, wenn sie laufen.
Und was ich meistens sehe, ist entweder gar kein Output oder quasi die ganze Zeit Prints oder Console Logs, wie auch immer, von was das Skript gerade tut.
Also so ESLint sagt halt, jetzt mach ich das, jetzt mach ich das, jetzt mach ich das, jetzt mach ich das, jetzt mach ich das, jetzt mach ich das. das.

[49:24] Und ein paar habe ich gesehen, die machen halt Punkt, Punkt, Punkt, Punkt, Punkt, Punkt, dass man weiß, das Terminal ist nicht eingefroren und irgendwie wird was kommen. Was Fanzigeres habe ich noch nie gesehen.
Ich habe auch noch nie gesehen, dass es eine Art Kalender Tagesauswahl gibt.
Weiß auch nicht, ob das notwendig ist.
Aber wer ist denn, geht das in die Richtung von Sachen, die man selber bauen müsste, selber bauen kann?
Loading States oder Advanced Input Felder wie wie Dates, Timestamps.
Genau, das sind alles Sachen, die man selber bauen kann. Oder jetzt gerade, wenn es um so eine ... Aber man kann das wirklich tun. Man kann das tun, ja, ja.
Oder jetzt gerade, also so der einfachste Fall, vielleicht so was gerade wie eine Fortschrittsanzeige, die du jetzt gerade genannt hast. Punkt, Punkt, Punkt.
Ja, also das ist halt so der einfachste Fall.

[50:13] Was aber viele Leute vielleicht auch nicht wissen, was man auf einem Terminal machen kann, Das ist ja nicht, so ein Terminal ist nicht zu 100% linear.
Es ist jetzt nicht so, dass du, du bist nicht darauf angewiesen, jetzt mal ein Console.log zu machen und das, was dann geprintet wird, steht für immer da.
Sondern die meisten Terminals unterstützen ja auch sowas wie das Wagenrücklaufzeichen, wer sich noch dran erinnert, wo du deinen Cursor wieder zurücksetzen kannst und Sachen überschreiben kannst, die du vorher schon aufs Terminal geprintet hast.
Das heißt, theoretisch, wenn du einen langlaufenden Prozess hast, könntest du sagen, ich gebe jetzt meine Fortschrittsanzeige aus, so als Text-Äquivalent der Progress-Bar, wie man sie aus der GUI auch kennt.
Und wenn ich dann einen Progress habe, dann kann man auch so bei Docker starten, wenn dann schon steht 10%, 50%. Ja, genau, Docker macht das genauso, genau.
Und dann setze ich halt die Zeile in dem Terminal einfach zurück und gebe eine geupdatete Progress-Bar wieder aus.
Das kann man mit diesen ganzen einfachen Terminal-Steuerzeichen natürlich selber bauen, aber auch da gibt es Bibliotheken für, die halt genau das machen.
Und ich glaube, das ist jetzt auch die Überleitung wo du vorhin drauf hinaus wolltest.
Wir haben dann irgendwann, ich konnte dann irgendwann selber meinen Augen nicht so ganz trauen, als ich das gesehen habe.

[51:39] Es gibt tatsächlich Node.js-Bibliotheken, die es dir erlauben, auf der Kommandozeile mit React zu arbeiten.

[51:47] Holy shit. Hat mich selber überrascht, als ich es gesehen habe.
Also für die Leute, die dann nach Google wollen, Ink heißt das Projekt.
Das das erlaubt es dir tatsächlich React-Komponenten so mehr oder minder, wie du sie aus dem Web halt auch kennst, für Konsolenanwendungen zu definieren.
Natürlich mit ein paar Einschränkungen. Also HTML funktioniert auf der Konsole halt nicht.
Das heißt, du bist darauf angewiesen, so die Komponenten zu verwenden, die Ink dann zum Beispiel mitliefert.
Da gibt es zum Beispiel eine Textkomponente. Die hat dann...
Die Props, die ich brauche, um irgendwie Text auf der Kommandozeile zu formatieren.
Farbe und, also da gibt es nicht viele Möglichkeiten, Farbe und Fett, ja oder nein. Das ist meistens so das, worauf es sich dann beschränkt.
So, aber immerhin, das ist halt schon eine Million Mal cooler, als sich irgendwie mit diesen Ansi-Escape-Color-Codes auseinandersetzen zu müssen.
Weil wer das einmal gemacht hat, never again. gern.
Die Listen hier insgesamt so sechs verschiedene Komponententypen auf, die man nutzen kann.
So Textbox, Newline, Spacer, Static und Transform.

[53:01] Genau. Und intern kann man aber dann eben mit den üblichen, also was so die, Programmlogik angeht, kann man ja die üblichen Kniffe benutzen, die man so von React kennt.
Und eben eben UseState, UseEffect und Co.
Du kannst genauso wie im Web einfach deine eigenen Komponenten definieren, so im einfachsten Fall halt irgendeine Function Component.
Du kannst, ich weiß nicht, ob es irgendwelche Einschränkungen gibt, aber ich habe bisher keinen von den üblichen React-Hooks gefunden, die du im Web nutzen kannst und unter Ink dann nicht.
Das heißt, du kannst auch Stateful-Components definieren mit UseState, UseEffect, das funktioniert alles.
Und kriegst da aber dann zum Beispiel auch eine Progress-Bar hin. zum Beispiel.
Also du könntest dann sagen, du definierst eine Progress-Bar-Komponente, wirfst dann als Prop vielleicht den aktuellen Progress als Number oder sowas da rein und formatierst das Ding dann entsprechend.

[54:02] Und ja, so genau wie mit React im Web auch.
Wenn du die Komponente aktualisierst mit veränderten Drops, dann rendert sich das Ding neu, resettet sich einmal auf dem Terminal und aktualisiert sich dann quasi in Place. Vielen Dank.
Und darüber kriegst du auch komplexe Input-Fields hin.
Wir haben darüber einen Input-Field zum Beispiel für maskierten Password-Input oder sowas gebaut, wie man es aus dem Web halt auch kennt.
Theoretisch haben wir jetzt nicht gemacht, aber könnte man theoretisch.
Theoretisch könntest du auch so ein richtig komplexes Passwort-Input-Field bauen, der dann irgendwie noch deine, wie man es aus dem Web halt auch kennt, der dann deine Passwortstärke irgendwie noch mit irgendeinem Stärkebalken oder Color-Codes oder sowas validiert.
Also die Fantasie ist die Grenze.
Naja, und halt die Textdarstellung im Terminal. Es muss halt am Ende immer noch als Text irgendwie darstellbar sein.
Ja, also was man so quasi quasi aus den ASCII-Tabellen oder wie auch immer kennt, an Zeichen kann man benutzen, oder?
Genau, wobei dir ja schon die komplette Welt von Unicode zur Verfügung steht. Ja, genau.
Emojis und so kannst du da auch drauf packen.
Alleine wie viele Unicode-Zeichen es gibt, um Boxen zu rendern.

[55:26] Runde Ecken, eckige Ecken, mit Schatten, ohne Schatten, einfache Linien, doppelte Linien.
Man kann so eine einfache Box auf dem Terminal auch schon sehr, sehr kreativ stylen. Also da gibt es doch schon einige Möglichkeiten.
Wenn man das will. Man sollte es natürlich auch nicht übertreiben, weil irgendwann wird es dann auch auf dem Terminal dann zur Reizüberflutung.
Ja, genau. Und jetzt nur mal so dahergesponnen. Also man könnte wahrscheinlich mit Ink, könnte man damit auch so was wie, keine Ahnung, Tetris programmieren?
Wahrscheinlich schon, oder? oder?
Weil das klingt ja so auch noch, also wenn man so ein State hat und den dann einfach aktualisiert und alles...
Also wahrscheinlich schon. Ich hab's jetzt noch nie ausprobiert, aber ich, Richtig schön nerdig. Total unnütz, aber ... Es gibt auch einen ...
Ink bringt auch so ein paar spezielle Hooks mit, die jetzt im Web vielleicht nicht so viel Sinn machen, aber wo du halt zum Beispiel auf einen speziellen Keypress oder sowas reagieren kannst.

[56:29] Sehr geil. Ja, cool.
Also das ist dann sozusagen die, Spitze der Evolution, wenn man man wirklich komplett steil gehen will und einem das Standard-Oakcliffe und die Plugins, die es dafür gibt, wenn die dann nicht ausreichen.
Aber es macht natürlich am meisten Sinn bei Dingen, wo States sich aktualisieren.
Also so bei Sachen, die einmal irgendwie gerendert werden, da braucht man sowas wie Ink wahrscheinlich eher nicht.
Ich find's auch da sinnvoll, wo du.

[57:07] Präsentationskomponenten hast, die du häufig wiederverwenden willst.
Also wir haben das bei uns in der CLI zum Beispiel keine Ahnung, du hast, so ein paar Dutzend Commands, die einfach nur get irgendwas machen und dann lädst du irgendein, dann lädt das irgendeine Ressource von der API runter, soll es einfach nur ausgeben. Und.

[57:31] Da bietet dir so eine, wenn du da so eine kleine Bibliothek an fertigen React-Komponenten hast.

[57:39] Auch da wieder genau wie im Web, da bietest du deinen Entwicklern dann so einen Baukasten an fertigen Komponenten, an denen sie sich bedienen können, um da auch so ein bisschen Konsistenz ins Look and Feel reinzukriegen, damit jetzt nicht jeder seine Detailansicht oder seine Tabellenansicht oder sind sie wirklich sicher, dass sie diese Ressource löschen wollen, Confirmation Dialog, immer wieder from scratch neu programmieren müssen.
Ja, macht total Sinn. Ja, hast recht.
Und habt jetzt nochmal so gefragt, wie ist das bei euch?
Habt ihr dann irgendwie so ein Team oder eine Person, die sozusagen da den Hut auf hat und diese Komponentenbibliothek zentral irgendwie pflegt, die alle nutzen?

[58:28] So zentralisiert haben wir es bisher nicht. Wir sind aber auch noch so ein bisschen dabei, unseren Prozess darum zu finden.
Ja, aber macht auch da total Sinn. Die Analogie eben zu den Designsystemen, die wir im Frontend ja auch nutzen.
Ja, sehr, sehr cool. Wer testet das dann so?
So von der UX her? Gibt es da, weil ich frage gerade, normalerweise ist ja das Übliche, man zeigt es Kollegen, Kolleginnen und sagt, mach mal.
Kann man da genauso machen. Genau. Erzähl mal, wie viele Leute testen das normalerweise?
Und gibt es da schon auch so Best Practices?
Ich würde ja hoffen, es gibt weniger Best Practices, aber wahrscheinlich, wer weiß.

[59:14] Wie viele Leute testen das? Also es geht jetzt gar nicht so drum, wie viele Leute testen das, aber was passiert denn normalerweise, wenn du jetzt zum Beispiel sagst, du hast hier das neueste Feature dran gebaut, was passiert danach oder davor?
Im Idealfall kann man es dann genauso machen, wie man es mit einem ganz klassischen User-Test auch machen würde.
Das heißt, dann sucht sich irgendein, mehr oder weniger Freiwilligen dafür raus und im einfachsten Fall gibst du ihm eine Aufgabe, versuch mal über diese CLI, dein WordPress zu installieren, denk bitte laut dabei und dann setzt du dich daneben und beobachtest und merkst, was man alles besser machen kann.
Der neueste Trend ist übrigens nicht mehr laut denken zu lassen, weil Leute sich anders verhalten, wenn sie laut denken müssen, weil sie dann bewusst über die Sachen nachdenken, die sie tun.

[1:00:10] Ich bin da definitiv nicht auf dem neuesten Stand.
Wollte es auch nur am Rande erwähnen. Aber was ich jetzt schon drüber nachdenke, hat man da vorher so ein Design oder passiert das Design halt eher währenddessen?
Weil was ich ja schon oft in der Webentwicklung im Frontend habe, ist, dass ich ein Design übersetze in Browsersprache.
Wenn ich jetzt aber selber für mich quasi Tools entwickle, dann mache ich immer erst mal die Funktionen, die ich brauche und danach überlege ich mir, wie könnte es eigentlich ausschauen.
Das heißt, wenn ich jetzt eine CLI schreiben würde, würde ich mir auch erst mal, alle Funktionalitäten zusammenbasteln, damit ich jetzt schon mal theoretisch machen könnte, was ich brauche. Und dann würde ich mir denken, ist aber nicht so hübsch, ich brauche noch einen Loading State.
Also wir sind bei uns tatsächlich nicht mit dem großen Upfront-Design gestartet.
Weil wir sind, also unser Projekt, direkt, das ist auch so intern so als Ergebnis, eines Hackathons entstanden.
Und wir haben tatsächlich damit angefangen, dass wir einfach so ein bisschen drauf losprogrammiert haben.
Wir hätten uns wahrscheinlich ein paar Umwege sparen können, wenn man tatsächlich mit einem UX-Konzept für die CLI angefangen hätte.
Also ich würde das tatsächlich empfehlen, damit einzusteigen, weil ich vielleicht auch durch Schmerz gelernt habe, was passiert, wenn man das nicht tut.

[1:01:38] Weil wenn du einfach drauf loscodest und dann kommen so auf, durch natürliches Wachstum immer mehr und mehr Subcommands zu deiner TLI dazu, du merkst dann irgendwann, dass sich so ein paar, dass sich Inkonsistenzen einschleichen, dass dann vielleicht mal ein Flag beim einen Subcommand anders benannt ist als bei dem anderen oder sich vom Wording her Inkonsistenzen einschleichen. Dann heißt es, keine Ahnung, dann heißt es Project Delete und Domain Remove.
Das ist halt kompletter Quatsch, weil das kapiert der ja keine Sau mehr.

[1:02:15] Fangen wir mit Archive noch an. Ja, genau.
Und manchmal heißt es beim Delete dann minus minus Confirm und dann heißt es minus minus Force und es tut aber eigentlich beides das Gleiche.
Du nennst gerade noch Beispiele, da könnte ich mir zumindest vorstellen, das wäre jetzt noch einfach zu ändern.
Ich denke jetzt gerade auch dran, wenn ich eben zum Beispiel dann im Web mal was ändern muss, dann sind die schmerzhaften Dinge wirklich, wenn sich so die Layout-Organisierung so komplett ändert.
Und wenn ich jetzt hier diesen Text aus dieser Box rausnehme, dann brauche ich statt Flexbox, muss ich dann Grid verwenden.
Oder ein Beispiel, manchmal in 90% der Fällen kann ich zum Beispiel im Web Text abpunkten und in 10% der Fällen ist es aber in irgendeinem Flex-Container, wo gar nichts mehr geht.
Und dann ist es so, nee, wir machen das jetzt einfach ganz anders.
Wir machen hier nicht abhunken, wir lassen den Text einfach umbrechen. Ist ja sowieso besser.
Aber du sagst schon, dass auch das Design im Nachhinein hinzufügen oder abändern kann mit Schmerz verbunden sein in deiner Erfahrung?
Das kann mit Schmerz verbunden sein, weil anders als im Web musst du bei einer CLI ja tatsächlich auch immer damit rechnen, dass irgendwer ankommt und skriptet mit dem Ding.
Ah, ja, Frechheit. Ja, frech.

[1:03:35] Musst du im Web auch mitrechnen, also du musst auch damit rechnen, dass irgendwer deine Oberfläche scrapt und sich irgendwie automatisch da durchklickt.
Das ist meistens so mit weniger Erwartungen verbunden. So, wenn sich dann die Oberfläche ändert und dein Scraper funktioniert nicht mehr, dann sagst du halt meistens, ja, so, sorry, selber schuld.
Das ist bei Kommandozeilen halt nicht so, weil da ist häufig so eine gewisse Erwartung der Stabilität mit verbunden.
Wenn du jetzt irgendwie auf einmal einen Parameter umbenennst oder einen Command umbenennst, Herzlichen Glückwunsch, du hast gerade bei 200 Leuten irgendwie die Skripte kaputt gemacht Uiuiui.

[1:04:09] Kommt drauf an. Also Abwärtskompatibilität ist da, glaube ich, eine relativ große Anforderung. Zumindest wenn Nutzung in Skripten tatsächlich einer deiner erklärten Anwendungsfälle ist.
Gibt es auch Mittel und Wege drumherum. Ich habe noch eine merkwürdige Frage.
Da gibt es ja vermutlich, jetzt aber nicht sowas wie ein Tracking, also ihr könnt jetzt vermutlich nicht von euren Usern wissen, welche Befehle haben sie in welcher Reihenfolge eingegeben?
Oder haben die Enter gedruckt oder Leertaste? Da ist jetzt nicht so ein Google Analytics drauf, oder doch? Nee.
Sonst hätte ich jetzt Angst vor meinem Terminal.

[1:04:54] Ich würde lügen, wenn ich behaupten würde, dass ich nicht schon mal versucht hätte, mich da schlau zu machen.
Ja, klar. Tatsächlich gibt's da nix. Es gibt aber auch niemanden, der irgendwie drüber schreit. Es gibt auch keine API-Tests dann.
Genau. Was man natürlich machen kann, ist zum Beispiel irgendwie über Access-Log-Analyse, seitens der API dann zu gucken, was ist so ... Ja.
Welche API-Requests kommen jetzt zum Beispiel über die CLI rein?
Kann, dann versuchen, irgendwie Schlussfolgerungen zu ziehen, was passiert da jetzt, wie, wo, wann, in welcher Reihenfolge, aber du kannst jetzt nichts sehen. Ja gut, dann muss man jetzt zumindest mal Enter drücken oder so was und dann sieht man jetzt nicht, was genau die Person da jetzt tippt oder wieder weggetippt hat.
Ja, genau, also du kannst jetzt nicht irgendwie einzelne Keystrokes oder sowas analysieren.
Ihr müsst einfach euer Programm zusammen mit einer richtig coolen Tastatur liefern und die telefoniert nach Hause.
Kreditkarten werden auch noch mitgeschickt.

[1:05:56] Die Technik für Herausforderungen liegt ja auch daran, dass zumindest wenn du so eine Command-basierte CLI hast, das Programm wird ja erst dann ausgeführt, wenn du auf Enter gedrückt hast.
Das heißt, du kannst jetzt nicht... Du müsstest dich ja ins Terminal des Users selber einklinken, um rauszufinden, wie kommt er oder sie jetzt zu diesem Befehl, der dann am Ende ausgeführt wird.
Also das ist... Aber es gibt ja schon auch so Sachen, die sich dann dann zu öffnen. So wenn ich jetzt dran denke, in irgendwelche Backend-Konsolen.
Ich kann zum Beispiel eine Rails-Konsole aufrufen und dann bin ich ja irgendwie in so einer Rails-Konsole drin.
Stimmt. Dann bist du in der Software und dann kannst du theoretisch jeden Keystroke und die Timings dazwischen tracken, wenn du so eine interaktive selber so eine interaktive Konsole hast.

[1:06:44] Wir haben ja gerade über sozusagen Umgestaltung und Lieberlassen, weil vielleicht möchte jemand ja den Output scrapen und wenn der sich verändert, dann kann nicht mehr gescrapet werden.
Genauso, was so die Rückwärtskompatibilität für Flags und Argumente angeht, also dass man das stabil hält.
Genau, also letzteres, das ist, glaube ich, noch so, da wäre ich selber drauf gekommen, was so die Stabilität der Ausgabe angeht, da wäre ich vielleicht schon mal nicht so sehr drauf gekommen, dass ja Leute das dann wieder irgendwie den Output weiterverarbeiten.
Aber macht auch total Sinn. Gibt es noch irgendwelche Dinge, auf die man achten sollte, die einem sonst auf die Füße fallen?
Was können User machen, mit denen man nicht rechnet?

[1:07:36] Gerade im Terminal hast du es ja so, dass du häufig ... So gerade die Linux-Leute machen das ja gerne, gerne, dass sie irgendwie Output aus einem Command dann wieder ins nächste Command reinpipen und sowas.
Ja, das finde ich auch einen relativen Standardfall, irgendwie mal von einem Webbrowser oder von einer Webseite irgendwas runterzuladen und danach den Text, weiterzuverarbeiten, so durchsuchen, zu filtern.
Ja, genau, also da sollte man halt auf jeden Fall mit rechnen.
Was muss man dafür tun, dass man dem nicht im Weg steht?
Ich denke mir jetzt mal gerade so einen ganz einfachen Anwendungsfall aus, so du hast vielleicht irgendeinen einen List-Command, das gibt dir eine Tabelle aus.
Und jemand pipet diese Tabellenausgabe dann durch Grepp oder so was.
Einfach, weil du irgendwie suchen, filtern willst oder so was.
Ich würde dann in dem Fall darauf achten, dass du ... Also, was dem zum Beispiel im Wege stehen würde, wäre, wenn dann alle möglichen Kontrollsequenzen für Farb-Output, also für Color-Output mit da drin stehen ...

[1:08:39] Weil das bringt so deinen regulären Ausdruck im Grep dann vielleicht auseinander.
Aber wie kann ich denn erkennen, dass so ein Grep da hinten dran hängt und dann gebe ich keine Farbcodes aus? Kann ich das sehen?
Ja, du kannst in fast allen Programmiersprachen über irgendeine Library-Funktion testen, ob der aktuell laufende Prozess an ein TTY, also an ein echtes Terminal, attached ist.
Und wenn du selbst wenn du den Befehl in einem Terminal startest, aber dann per den Output per Pipe irgendwann das hinschickst, findest du das darüber raus und kannst entsprechend drauf reagieren.
Okay. Und die meisten Frameworks machen das auch schon automatisch.
Also die meisten Frameworks, die jetzt zum Beispiel sagen, ich unterstütze Color Codes, farbige Ausgabe oder sowas, die reagieren automatisch darauf und stellen diesen Color Output dann, aus, wenn sie merken, hey, ich laufe jetzt jetzt in einem Script oder mein Output wird irgendwo hin weitergepiped und ich laufe nicht in einem echten Terminal.
So, dann spart man sich diese farbige Ausgabe.
Ja, super. Ja, spricht dann ja auch für die Nutzung eines Frameworks, das dann solche Dinge irgendwie mit einpreist. Genau.

[1:09:57] Ich würde auch immer, das ist dann vielleicht so ein User-Präferenz-Ding, ich würde auch immer ein zusätzliches Flag anbieten, um dem dem User quasi die Möglichkeit zu geben, hey, ich will diesen Farboutput nicht haben.

[1:10:10] Ja. Das habe ich auch schon gemerkt. Also gerade, wenn man irgendwie mit Farben auf dem Terminal arbeitet.

[1:10:20] Die hat man nicht immer unbedingt unter Kontrolle, weil man nie genau weiß, wie hat der User jetzt gerade sein Terminal überhaupt konfiguriert.
Das wollte ich gerade fragen, wenn du jetzt zum Beispiel Gelb einstellst, ist es immer Gelb?
Oder gibt es da quasi, wie bei VS Code Color Themes, dass ich sage, das ist mein Italic-Text, der kann einmal gelb sein oder der kann einmal blau sein oder er wird immer hell dargestellt?
Das kommt tatsächlich auf den User an, was für Präferenzen der eingestellt hat.
Also unter macOS-Items, da kann man ja jeden Color-Code einzeln anpassen.
Unter Windows muss ich jetzt gerade ... Ich habe mich vorhin schon geoutet.
Ich bin jetzt nicht der harte Windows-User. Also, da weiß ich gar nicht, was man da genau alles einstellen kann.
Und manchmal muss man halt auch ein bisschen aufpassen, wie...

[1:11:16] Wie man jetzt mit dem Farbschema des Users zusammenarbeitet und auch wie man Farben ausgibt.

[1:11:22] Es gibt zum Beispiel Color Codes für das Terminal, wo ich einfach nur sagen kann, dieser Text soll jetzt gelb sein.
Und je nachdem, mit welchem Farbschema das Terminal des Users läuft, ist es dann vielleicht ein anderes Gelb.
Keine Ahnung, ich denke jetzt gerade an so klassische Unterscheidungen.
Helles Farbschema, dunkles Farbschema im Terminal.
Bei hellem Hintergrund habe ich dann wahrscheinlich lieber einen etwas dunkleren Gelbton, weil so hellgelb auf weiß ist eher so mäh.
Aber auch dunkelgelb auf weiß kann mäh sein. Ja, aber dann kannst du es wenigstens lesen.
Je nachdem. Je nachdem, wie dunkel. Und beim dunklen Farbschema ist es dann halt andersrum.
Aber dann kann ich mich zumindest darauf verlassen, wenn ich einfach nur sage, diese Textausgabe soll jetzt gelb sein, dass es sowohl bei einem hellen und einem dunklen Farbschema auch okay aussieht.
Nee, aber ich verstehe schon generell, dass es vermutlich gar nicht so unwichtig sein kann, dass man im Notfall sagen kann, du gib mir das mal einfach ohne Color.
Hauptsächlich kannst du lesen. Und wo du dich halt richtig mit ins Knie schießen kannst, ist bei modernen Terminals kannst du halt tatsächlich, also du kannst da theoretisch 32 Millionen Farben verwenden.
Also du kannst einfach, oder warte mal, 3-Bit.
Wahrscheinlich gibt es sogar Wide-Gamut-Terminals mittlerweile. Mittlerweile.
Die neuen Farbräume alle unterstützen. Wenn du dann sagst, ich möchte diesen Text jetzt tatsächlich mit.

[1:12:47] Hexcode für was auch immer hell, pastell, gelb ist ausgeben und jemand startet das Ding dann in seinem Terminal im Nicht-Dark-Mode, dann musst du halt damit rechnen, dass das für den User einfach nicht so cool aussehen wird.
Und der will dann gerne die Option haben, diesen Color Output zu deaktivieren.

[1:13:09] Oder man macht das halt nicht. Man gibt keinen Text in Pastellfarben aus.
Das geht nicht davon aus, dass jeder User sein Terminal im Dark Mode laufen hat. Auch wenn man es manchmal gerne würde.
Ja, das ist schon gut, wenn man die Option anbietet.
Ich hätte jetzt zwischenzeitlich noch eine andere Frage. Ich hatte ja vorhin gerade schon mal Homebrew erwähnt.
Kommt dann alles automatisch so? Kann ich dann alles automatisch per Homebrew runterladen? Oder muss ich jetzt als Entwicklerin von meinem CLI-Tool was Spezielles machen, damit es das bei Homebrew auch gibt?
Homebrew war tatsächlich ein bisschen Arbeit.
Erzähl mal. Das kommt nicht automatisch mit.
Homebrew funktioniert so, dass du.

[1:14:01] Homebrew hat verschiedene Tabs. Also die haben ja so ein ganz eigenes Vokabular.
Ich weiß gar nicht, was ist die Metapher dahinter? Ist das Kaffee oder ist es Bier? Ich glaube, es ist Bier.
Homebrew klingt nach Bier, genau. Das heißt, die haben verschiedene Tabs, also quasi verschiedene, die Linux-Leute würden sagen, verschiedene Paketquellen.
Und jedes Tab ist quasi ein Git-Repo, wo Formulas für die einzelnen Pakete drin liegen.
Das heißt, wenn man jetzt seine eigene Software per Homebrew ausholen möchte, entweder man klingt sich in das Homebrew-Standard-Tab mit ein.
Das ist dann, ich muss gestehen, das habe ich noch nie gemacht.
Oder man erstellt halt sein eigenes Tab. Das ist dann ein Git-Repository, was irgendwo in eurer GitHub-Org liegen muss.
Das muss einem bestimmten Namensschema folgen und das muss einer bestimmten Dateistruktur in diesem Repository folgen.
Und für das Paket liegt dann da jeweils eine Ruby-Datei, die quasi den Installationsprozess dieses Pakets beschreibt.

[1:15:15] Wir machen das mittlerweile so.
Man könnte in dieser Formule alles Mögliche machen.
Man könnte da jetzt auch sagen, lad dir die aktuelle Version der CLI-Software per Git runter und installiere noch eine Node.js als Dependency, damit das alles funktioniert.
Wir haben es uns da jetzt einfach gemacht und laden dann an der Stelle einfach wieder diese präpaketierten, gebundelten Pakete mit eingebautem Node-Interpreter mit runter, weil das ist ein Tarball, den kann man entpacken, man weiß vorher, welche Tar-Prüfsumme hat das, kann das noch einmal gegenprüfen, damit man sicher sein kann, hey, es ist jetzt wirklich auch unverändert die Version angekommen, die du haben willst.

[1:15:57] Und automatisiert haben wir das über eine GitHub-Actions-Pipeline.
Das heißt, immer wenn jetzt eine neue Version der CLI released wird, dann wird diese Formula einmal aktualisiert, dass da quasi die aktuellste Version runtergeladen wird.
Es wird einmal die Fahrprüfsumme in dieser Formula aktualisiert, damit man das entsprechend prüfen kann.
Und dann funktioniert auch so dieser ganze normale Brew-Upgrade-Prozess, den man so von Homebrew kennt.
Das war tatsächlich ein bisschen Arbeit.
Ich hätte mir das fast auch vorstellen können, dass man da so, ähnlich wie Podcasts zu Spotify plumpsen, dass solche CLI-Tools automatisch von Homebrew aufgenommen werden.
Also vielleicht gibt es da einen einfacheren Weg und ich habe ihn einfach nicht gefunden, das will ich jetzt nicht ausschließen, also falls irgendwer von euren Hörern da einen besseren Weg kennt, schreibt mir eine Mail, ich bin dafür feedback-offen.

[1:16:55] Wir hatten ja auch vorhin schon mal kurz drüber gesprochen, über dann die Anwendungen zu bauen und verteilen.
Gibt es aber noch was Spezifisches, was du darüber erzählen möchtest, außer Homebrew?
Wenn du sagst, da war es schwierig, was war leicht?
Leicht war das Docker-Image, das war relativ dankbar, weil ein Docker-File zu bauen, bau auf dem Standard Node.js-Image auf, kopiere deine App da rein, gut ist.
Das ist relativ dankbar, vor allem da weißt du, dass das dann auch so gut wie überall funktioniert.
Du weißt, dass das auf dem Mac gleich funktioniert wie unter Linux, gleich funktioniert wie unter Windows.

[1:17:38] Zieht natürlich wieder den Haken nach sich. Nicht jeder ist jetzt vielleicht Docker-User, gerade wenn du in deiner CLI viel mit lokalen Dateien interagieren möchtest.
Also kommt halt immer so ein bisschen drauf an, was dein Programm dann tut.
Ist das immer so ein bisschen schwierig, weil dann musst du wieder mit den Volumes aufpassen.
Halt alle Probleme, die man bei Docker so hat, wenn man mit lokalen Dateien arbeiten möchte.

[1:18:03] Ansonsten ist das eigentlich ein sehr, sehr dankbarer Distributionsweg, aber es ist halt nicht so die nahtloseste Integration.
Es gibt dann natürlich so die ganzen plattformspezifischen Paketmanager.
Also ich könnte auch sagen, ich packe meine CLI einfach als Paket auf npm und dann soll der User halt einfach einen npm install oder ein install-g für Global Installation machen.
Das hat dann wieder den Haken, ich weiß ja nicht, welche welche Node.js-Version der User installiert hat.
Also vielleicht hat der eine Node.js-Version laufen, mit der ich meine Software gar nicht getestet habe.
Und keine Ahnung, oder vielleicht läuft er noch auf Node 12 oder keine Ahnung was.
Das heißt, das macht es dann schwierig, Garantien abzugeben, dass das Ganze wirklich so funktioniert.
Das kommt auch so ein bisschen darauf an, mit welcher Programmiersprache man halt arbeitet.
Also Go-Modules ist da relativ dankbar.
Da hat man dann irgendwie so einen Go-Install-Einzeiler, bei dem man sich dann häufig auch darauf verlassen kann, dass das irgendwie funktioniert.
PHP hat Composer. Das ist meistens auch ein akzeptables Distributionsmedium.
Wobei da auch natürlich, da kann es wieder Cross-Dependencies oder Konflikte geben, also.

[1:19:20] Wenn man irgendeine Möglichkeit hat, so ein isoliertes Installationspaket zu verteilen, ist das eigentlich immer am besten Oder zumindest am bietet am wenigsten Fehlerpotenzial beim Endanwender.

[1:19:35] Ich mache eine nahtlose Überleitung zu einer wiederum ganz anderen Frage Wir haben vorher drüber gesprochen, wir haben Plex am Anfang wie Help oder List, um erstmal zu schauen, was wir machen können.
So ein paar Sachen, die ich in der Vergangenheit benutzt habe, je länger wir darüber reden, fallen mir viel mehr Beispiele ein, waren auch Tools, bei denen ich mich dann einloggen musste.
Wir haben nicht drüber nachgedacht, hat einfach funktioniert.
Aber anscheinend kann ich mich ja auch authentifizieren.
Oft so auch bei Git-Tools. Wie kompliziert ist es denn, so ein Login zu machen?
Ist das Business as usual und macht man standig oder ist das furchtbar kompliziert?
Es kommt so ein bisschen darauf an, wie der Authentifizierungsflow genau aussieht.
Und es kommt auch so ein bisschen darauf an, was für Möglichkeiten man auf dem Endgerät des Users hat. Ja.

[1:20:32] GitHub macht das zum Beispiel ganz, ganz schön, da hast du einfach deinen Standard O-Out-Login-Flow, das heißt, du startest deinen Login-Prozess über die Kommandozeile und die CLI tritt dann quasi als O-Out- oder OpenID-Connect-Consumer auf und dann geht einmal ein Browserfenster auf, du darfst dich dann beim Provider irgendwie einmal einloggen, musst dem Client dann Zugriff erteilen auf die Ressourcen, auf die er angefordert hat. die angefordert hat.
Und dann kriegst du quasi den API-Token, das geht zurück an die CLI, der kann sich das irgendwo in seinem Konfigurationsverzeichnis wegspeichern und dann bist du authentifiziert.
Das setzt natürlich erstmal voraus, dass du einen OAuth-Provider hast, gegen den sich deine Anwendung authentifizieren kann. Also der muss halt da sein.
Und du musst einen Browser haben, den du öffnen kannst. Wenn du jetzt auf dem Server unterwegs bist, funktioniert das irgendwie auch nicht so gut. Ansonsten, das Minimum, was man meistens machen kann, ist hey, du brauchst einen API, Token, um auf diese API zuzugreifen, bitte copy-paste den hier jetzt irgendwo rein, das ist jetzt nicht so der ideale Nutzerfluss, weil du zwingst den Nutzer dann dazu, sich wieder in irgendein anderes, dann doch wieder per Web irgendwo anders einzuloggen und sich dann, von Hand einen API Token zu erstellen und den irgendwo reinzukopieren, das ist nicht so, ideal, aber das funktioniert halt meistens.

[1:21:58] Manche Tools machen es ja auch so, dass man direkt in der CLI seine Zugangsdaten eingeben kann.
Dass du in der CLI direkt nach Username und Passwort gefragt wirst.
Ich glaube, du hast die größte Störversteller, dass, wenn man ein Passwort tippt, gar nichts erscheint, auch keine Sternchen. Ja.
Und dann ist das so, äh, wo bin ich?
Was mache ich hier? Ich drücke Enter und gucke, was passiert.
Und was machst du mit sowas wie wie zwei Faktor out oder sowas, weil das müsstest du dann ja theoretisch auch alles supporten.
Und Passcodes.
Das wäre ideal, das stimmt. Ja.
Habe ich noch nie gearbeitet mit. Auf der TLE auch. Es reicht noch nicht.
Ich auch noch nicht. Aber man sollte es sich angucken. Ich dachte, der Chef sagt es ja. Man muss ja nicht jeden Trend mitmachen.
Ja, genau. Ach, das ist ja bald wieder verstanden. Das Posted am Bildschirm funktioniert schon immer.
1, 2, 3, 4, 5, 6, 7, 8, 9, ausgeführt Zeichen. Äh.
Genau, und zwei Faktor und One-Time-Code und so. Pff, man braucht so was.
Ja, wird auch auch überbewertet.

[1:23:09] Okay, ich würde jetzt noch mal ein bisschen noch mal zu UX auch zurückkommen oder dann auch zu UI.
Etwas, womit ich in den letzten Jahren immer wieder mehr konfrontiert wurde mit User-Inputs, waren Emojis.
Und ich weiß, an sich ist es UTF-8, aber manchmal bin ich doch einfach ganz happy, dass es doch irgendwie einfach funktioniert.
Spannend wird es zum Beispiel auch sehr, wenn User anfangen, Titel von Dingen mit einem Emoji zu prefixen und du versuchst das dann zu sortieren und fragst dich dann, ist das Emoji eigentlich vor A oder hinter Z?
Es gibt dann auch Browser, die können das dann, oder ich weiß gar nicht, ob es Browser sind oder Sprachen, die können mit Emoji sortieren oder die jumpen mal über das Emoji drüber und sortieren dann erst alphabetisch.
Aber Frage der Fragen, ich kann jetzt ernsthaft nicht sagen, ob ich schon gesehen habe oder nicht, können wir Emojis verwenden.
Können wir. Also die...
Da ist ein Sternchen Text mit dran.

[1:24:14] Physikalisch gesehen können wir, wir wollen aber nicht. Die meisten modernen Terminals unterstützen das.
Ich muss jetzt da wieder den Disclaimer nennen, ich weiß nicht, wie sich so eine Windows CMD prompt verhält.
Es gibt eh nur die Android Emojis, die vielleicht nicht funktionieren.
Das kann ich jetzt ganz ehrlich nicht sagen. Ähm...
Also wir können das. Und ich finde auch, das bringt durchaus seinen Mehrwert, wenn man es irgendwie in Maßen einsetzt.
Also ja, ich finde zum Beispiel Jan macht das sehr, sehr hübsch.
Weil Jan es schafft, irgendwie über geschickt gewählte Emojis.

[1:24:53] Relativ gut erkennbare Statusinformationen rüberzubringen. Das heißt, man muss jetzt nicht groß den Text lesen.
Wow, Entschuldigung, ich habe meinen Terminal aufgemacht. Ach, natürlich sind da Emojis.
Da steht ja hier, Spikeldone in 70 seconds.
Hab ich noch nie gesehen. Ja, also ich finde, das bietet halt schon das Potenzial, dass man so auf einen Blick, ohne jetzt wirklich die Textausgabe lesen zu müssen, sehr, sehr schnell erfassen kann, was da gerade passiert.
Ja, klar, dafür sind ja quasi da so ein bisschen Highlighter.
Bringt schon seinen Wert.
Du musst jetzt visuell einfach nur noch auf das Spikelemoji achten und du weißt so, okay, ja, ein Install hat geklappt. Herzlichen Glückwunsch. Ja.
Was man nicht machen sollte, ist sich nur darauf zu verlassen.
Also ich würde jetzt davon abraten, eine CLI so zu bauen, dass jetzt wichtige Statusinformationen nur über irgendwelche Emojis kommen, weil so dann sind wir wieder beim Thema, was ist auf dem Terminal, wo statt einem Emoji einfach nur ein Viereck mit einem Fragezeichen drin dargestellt wird.
Das haben wir ja auch alles bei der Frontend-Web-Entwicklung.
Das ist genauso mit Menüs, die nur aus Icons bestehen.
Disclaimer, Icons sind bis heute auch immer noch nicht selbsterklärend.
Man lernt, was irgendwann der Explorer ist, so eine File Icon, aber der Rest ist rausfinden. Ja.

[1:26:19] Genau.

[1:26:26] Hast du dir schon mal auch bewusst dann drüber Gedanken gemacht, mit Fehlerfällen umzugehen?
Also ich habe es ja vorher genannt, als ich die Plop-Files geschrieben hatte, für API-Requests oder Fetch-Requests zu generieren, wollte ich dann auch so Fehlermeldungen zurückgeben.
Zum Beispiel, wenn man jetzt nicht wüsste, wie ich das trimmen könnte, zum Beispiel zu sagen, hey, du hast mit dem Space losgelegt, mach das mal ohne. oder wir erwarten gerade eine KMLK-Syntax, das scheint uns eine Hyphen-Syntax zu sein.
Wie bist du mit solchen Situationen umgegangen, wenn es die schon gab?
Ich finde das sehr, sehr nützlich, vor allem, weil du, also gerade wenn es jetzt um so Input-Flag-Namen oder sowas geht, das ist halt schon eine relativ.

[1:27:12] Hohe kognitive Leistung, die du da bringen musst, gerade bei komplexen Commands, die irgendwie von, selbst wenn du vorher gerade die Hilfe-Seite aufgerufen hast, um dir dann zu merken, welches Command oder welches Flag muss ich da jetzt genau an dieses Command irgendwie übergeben und welches Format wird da erwartet, da finde ich schon, da könnte ich mir zum Beispiel vorstellen, dass man versucht, irgendwie so eine Art, Fuzzy-Matching zu bauen zwischen, hey, welche Commands, sorry, welche Flags sind denn überhaupt für dieses Command zum Beispiel definiert, welche habe ich bekommen und welche, welche, die ich nicht kenne, sehen aber vielleicht Flags ähnlich, die definiert sind.
Und dann könnte ich dem User vorschlagen, hey, dieses Flag, was du hier angegeben hast, das gibt es nicht, aber es gibt folgende zwei Flags, die irgendwie so ähnlich aussehen. Meintest du eins von denen?
Das fände ich sehr, sehr entgegenkommend.

[1:28:05] Ansonsten gelten auf der Kommandozeile, glaube ich, so dieselben Prinzipien, die im Web halt auch gelten.
Also ich glaube, long story short geht es ja eigentlich immer darum, dass ich als User nachvollziehen kann, warum irgendeine Art von Eingabe, die ich gerade gemacht habe, nicht gültig ist und was ich tun muss, um das irgendwie zu korrigieren.
Und im Idealfall, wenn ich das ist vielleicht auch noch so ein Punkt wenn ich irgendwie fünf falsche Eingaben gleichzeitig gemacht hab, dann sollte ich dem User auch alle fünf Fehler gleichzeitig anzeigen und nicht, einen nach dem anderen wenn er jeweils den nächsten korrigiert hat.

[1:28:48] Und kann auch zustimmen, ist extrem hilfreich.
Also ich glaube, wir kennen es alle, das hat jetzt vielleicht, ich weiß nicht, wie viel es mit dem Tool zu tun hat, aber gerade im Testing-Bereich, da können manchmal sehr kryptische Fehlermeldungen kommen, die überhaupt nichts damit zu tun haben konnten. konnten. Meistens sind das ja so Compiler oder Parser-Sachen.
Und es ist einfach super, wenn da dabei steht, die Datei darf nicht mit einem spitzen Klammer losgehen.
Übrigens, es scheint so, als würdest du Module vom Typen her verwenden.
Ich glaube, du brauchst dafür noch den Parser. Guck mal, ob dir das hilft.
Weil in sehr vielen Fällen stimmt das dann tatsächlich.
Also vielen lieben Dank an alle da draußen, die das für uns schreiben.

[1:29:33] Da ist Git für mich auch so ein ganz großes Vorbild. Also ich finde gerade so die Hilfestellungen, die Git dir auf der Kommandoteile anbietet.
Weil ich weiß nicht, also alleine wenn man sich mal so den Git-Status-Output oder sowas anschaut, du siehst immer offensichtlich, in welchem Zustand ist mein Repo gerade. Dafür ist der Befehl halt da.
Der gibt dir aber auch alle Befehle aus, die du brauchst, um aus irgendeinem Status wieder rauszukommen.
Das heißt, wenn du eine bearbeitete Working-Copy hast, hast, dann sagt er dir so, du brauchst folgende zwei Befehle, um jetzt zu committen oder wieder zu reverten oder wenn du gerade einen Merch-Konflikt hast, dann sagt er dir so, du brauchst folgenden Befehl, um jetzt, weiterzumachen, du brauchst folgenden Befehl, um den Merch wieder abzubrechen und sowas.
Das geht, finde ich, sehr, sehr gut.

[1:30:26] Ich denke auch, wenn ich einfach den, sorry, ich habe gerade die Mute-Taste auch nicht gefunden, einfach mit dem Branch-Wechsel, schreibt der Git auch schon mal rein, du kannst pullen oder bist up-to-date.
Hat ja niemand gesagt, dass die da schreiben müssen, aber natürlich, das ist so eine Kleinigkeit, die extrem hilfreich ist.
Oder wenn man was prunen muss, weil irgendwas im Cache, bla bla bla.
Du hast recht, sehr hilfreiche kleine Sätzchen stehen da dabei.
Und immer sehr freundlich, aber auch prägnant.

[1:30:57] Also ich finde jetzt auf jeden Fall hält man die Augen ein bisschen mehr auf und also ich glaube, ich werde auf jeden Fall mehr auf den Output, aber auch so das Interface von Kommandozeilen-Tools schauen jetzt in nächster Zeit, nachdem wir jetzt hier heute Abend gesprochen haben.
Also echt sehr spannend.
Ich kann mir vorstellen, dass auch ein paar von unseren Hörerinnen solche Tools schon bauen.
Und genau, da würde mich auf jeden Fall auch interessieren, was ihr da gebaut habt und was ihr vielleicht für Erfahrungen habt.
Vielleicht gibt es ja noch irgendwelche Frameworks oder Kniffe, die wir heute nicht besprochen haben.
Wenn ihr Fragen habt zu dem Thema, kann man dich da anpingen, Martin? Auf jeden Fall, natürlich.
Auf welchen Kanälen bist du anpingbar? Ich bin auch gern für jederlei Feedback dankbar.
Wenn jemand sagt, hey, du hast da gerade totalen Quatsch erzählt, weil das muss man total anders machen.

[1:32:14] Ich kann hier jetzt nicht behaupten, die ultimative Autorität in dem Thema zu sein. Aber das sind wir ja alle nicht. Ja, genau.
Aber es ist auf jeden Fall ein super Thema, das du mitgebracht hast, auch weil das so fernab von dem ist, was so, womit wir sonst eigentlich, also wir haben schon damit zu tun, aber so eigentlich kreisen unsere Gedanken ja selten um diese Dinge.
Zumindest jetzt, also die von uns Hosts und möglicherweise auch die von den meisten Hörerinnen nicht.
Aber das das sollten sie vielleicht. Und das werden sie ab jetzt auch vielleicht eher mal.
Ja, cool. Genau, weil du gerade nach Kanälen gefragt hast. Ich glaube, LinkedIn und Co. sind wahrscheinlich am einfachsten.
Bist du auch auf Mastodon oder so? Da bin ich nicht. Da bist du nicht. Okay.
Wir werden deinen LinkedIn-Account auf jeden Fall in den Show Notes auch verlinken.
Vielen, vielen Dank, dass du da warst. Ja, sehr gerne. Ich danke auch.
Du bist wahrscheinlich auch nicht zum letzten Mal da. Wir haben auch gedacht, also du hast ja relativ viel so auf der Pfanne an guten Themen und da haben wir auch schon das ein oder andere noch uns rausgesucht, wo wir dich dann nochmal zu, interviewen und befragen werden in Zukunft.

[1:33:31] Genau. Aber das verraten wir natürlich noch nicht, was das ist.
Das wäre ja auch langweilig. Vielen lieben Dank fürs Kommen.
Vielen Dank auch von meiner Seite. Danke für eure Gastfreundschaft.
Gerne. Und unseren Hörerinnen auch vielen Dank fürs Zuhören.
Und wie gesagt, wenn ihr Feedback habt oder Fragen, dann meldet euch gerne.
Und dann hören wir uns nächste Woche wieder.
Bis dahin. Tschüss. Ciao, ciao. Ciao.

[1:34:00] Music.

[1:34:14] Bis zum nächsten Mal.